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DESCRIPTION 



SENDING- RECEIVING SYSTEM, SENDER APPARATUS, SENDING 
METHOD, RECEIVER APPARATUS, RECEIVING METHOD, RECORDING 
MEDIUM, AND PROGRAM 

Technical Field 

The present invention relates to a sending- 
receiving system, a sender apparatus, a sending method, a 
receiver apparatus, a receiving method, a recording 
medium, and a program. More particularly, the invention 
relates to a sending- receiving system, a sender apparatus, 
a sending method, a receiver apparatus, a receiving 
method, a recording medium, and a program for 
compensating data packets having gone missing during 
transmission or reception. 

Background Art 

Electronic networks have gained widespread 
acceptance today, and more and more services are being 
offered on these networks. Some networks are structured 
in wired fashion; others are constituted wirelessly. 

With the networks coming into general use, there 
has been a need for improving the reliability of 
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communication over any of the networks being used. For 
example, if some fault occurs on a network path over 
which target data is being transmitted, other paths are 
arranged to be formed so that the same data may be 
transmitted over the alternative paths to its destination 
in order to prevent data dropouts (as described 
illustratively in Japanese Published Unexamined Patent 
Application No. Hei 11-98161) . 

In recent years, wireless LANs (local area 
networks) have become popular as household networks 
because this type of network is easier to install than 
its wired counterpart. However, because of its particular 
characteristics, the wireless LAN tends to be less 
reliable than the wired LAN. 

For example, a wireless LAN setup obviously 
involves sending and receiving data wirelessly. The 
status of communication in that setup can easily 
deteriorate if a person crosses a data path between a 
transmitter and a receiver in communication or if 
humidity or other ambient factors in the household change 
significantly. The worsening state of communication can 
result in data dropouts or other irregularities during 
transmission or reception (i.e., communication). 

Methods have been proposed and implemented for 
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compensating video data that went missing for some reason 
during transmission or reception. For example, if data 
encoded using the MPEG (Moving Picture Experts Group) 
standard is to be decoded and if any video stream to be 
decoded has a missing packet, reproduction of that video 
stream is continued by supplementing it with the frame 
preceding that of the missing packet or some of the 
blocks in the preceding frame. 

Such error-disguising methods may be adopted by the 
decoder that processes video streams. This makes it 
possible to prevent inconvenience such as discontinuation 
of video presented to the user. 

On the other hand, errors caused by missing audio 
(data) packets cannot be disguised effectively by the 
same measures as those for addressing video data. Few 
effective methods have been proposed to compensate for 
missing audio packets. As a result, users are often left 
with unresolved irregularities stemming from missing 
audio data such as audio disconnections. 

Disclosure of Invention 

The present invention has been made in view of the 
above circumstances and provides arrangements for 
transmitting a given set of data a plurality of times 
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(i.e., redundant transmission) so as to prevent 
irregularities such as disconnections of video or audio 
offered to the user. 

According to a first embodiment of the present 
invention, there is provided a sending- receiving system 
including a sender apparatus for transmitting data and a 
receiver apparatus for receiving the data transmitted by 
the sender apparatus; wherein the sender apparatus 
includes: acquiring means for acquiring the data; sending 
means for transmitting to the receiver apparatus the data 
acquired by the acquiring means ; storing means for 
storing the data acquired by the acquiring means; and 
ordering means for ordering the sending means to transmit 
the data retrieved from the storing means; and wherein 
the receiver apparatus includes: receiving means for 
receiving the data transmitted by the sending means; 
determining means for determining whether or not the data 
received by the receiving means has been received 
already; and storage controlling means for discarding the 
data if the data received by the receiving means is found 
already received, the storage controlling means further 
storing the data if the data received by the receiving 
means is not found received already. 

According to a second embodiment of the present 
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invention, there is provided a sender apparatus 
including: acquiring means for acquiring data; sending 
means for transmitting the data acquired by the acquiring 
means; storing means for storing the data acquired by the 
acquiring means; and ordering means for ordering the 
sending means to transmit the data retrieved from the 
storing means. 

Preferably, the ordering means may retrieve the 
data from the storing means upon elapse of a 
predetermined time period following transmission of the 
data by the sending means and may order the sending means 
to transmit the retrieved data. 

Preferably, the sender apparatus of the invention 
may further include determining means for determining 
whether or not predetermined data is included in the data 
acquired by the acquiring means; wherein the storing 
means may store the predetermined data if the determining 
means determines that the predetermined data is included 
in the data; and wherein the ordering means may retrieve 
the predetermined data from the storing means and may 
order the sending means to transmit the predetermined 
data thus retrieved. 

Preferably, the sender apparatus of the invention 
may further include determining means for determining 
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whether or not audio data is included in the data 
acquired by the acquiring means; wherein, if the 
determining means determines that audio data is included 
in the data, then the storing means may store the audio 
data and a header attached to the audio data; and wherein 
the ordering means may retrieve the header and the audio 
data from the storing means and may order the sending 
means to transmit the retrieved header and audio data. 

Preferably, the header may be an RTP header. 

According to a third embodiment of the present 
invention, there is provided a sending method including 
the steps of: controlling acquisition of data; 
controlling transmission of the data acquired in the 
acquisition controlling step; controlling storage of the 
data acquired in the acquisition controlling step; and 
ordering the transmission controlling step to transmit 
the data retrieved from storage under control of the 
storage controlling step. 

According to a fourth embodiment of the present 
invention, there is provided a recording medium which 
records a program in a manner readable by a computer, the 
program including the steps of: controlling acquisition 
of data; controlling transmission of the data acquired in 
the acquisition controlling step; controlling storage of 
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the data acquired in the acquisition controlling step; 
and ordering the transmission controlling step to 
transmit the data retrieved from storage under control of 
the storage controlling step. 

According to a fifth embodiment of the present 
invention, there is provided a program for causing a 
computer to execute a procedure including the steps of: 
controlling acquisition of data; controlling transmission 
of the data acquired in the acquisition controlling step; 
controlling storage of the data acquired in the 
acquisition controlling step; and ordering the 
transmission controlling step to transmit the data 
retrieved from storage under control of the storage 
controlling step. 

According to a sixth embodiment of the present 
invention, there is provided a receiver apparatus 
including: receiving means for receiving data; 
determining means for determining whether or not the data 
received by the receiving means has been received 
already; and storage controlling means for discarding the 
data if the determining means determines that the data 
received by the receiving means has been received already, 
the storage controlling means further storing the data if 
the data received by the receiving means is not found 
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received already. 

Preferably, the determining means may determine 
whether or not the data is the already- received data by 
referencing a sequence number of an RTP header included 
in the data received by the receiving means. 

According to a seventh embodiment of the present 
invention, there is provided a receiving method including 
the steps of: controlling reception of data; determining 
whether or not the data received in the reception 
controlling step has been received already; and 
controlling storage of the data which is discarded if the 
determining step determines that the data received in the 
reception controlling step has been received already, the 
storage controlling step further storing the data if the 
data is not found received already. 

According to an eighth embodiment of the present 
invention, there is provided a recording medium which 
records a program in a manner readable by a computer, the 
program including the steps of: controlling reception of 
data; determining whether or not the data received in the 
reception controlling step has been received already; and 
controlling storage of the data which is discarded if the 
determining step determines that the data received in the 
reception controlling step has been received already, the 
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storage controlling step further storing the data if the 
data is not found received already. 

According to a ninth embodiment of the present 
invention, there is provided a program for causing a 
computer to execute a procedure including the steps of: 
controlling reception of data; determining whether or not 
the data received in the reception controlling step has 
been received already; and controlling storage of the 
data which is discarded if the determining step 
determines that the data received in the reception 
controlling step has been received already, the storage 
controlling step further storing the data if the data is 
not found received already. 

According to the invention, a predetermined item of 

♦ 

data is transmitted a plurality of number of times. That 
item of data may illustratively be audio data. 

According to the invention, when the predetermined 
item of data has been transmitted and received a 
plurality of times, the already-received data is not 
stored again. 

Brief Description of Drawings 

FIG. 1 is a schematic view showing a typical 
structure of a sending-receiving system embodying the 
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present invention; 

FIG. 2 is a block diagram showing a typical 
internal structure of a sender apparatus; 

FIG, 3 is an explanatory view of data to be 
transmitted by the sender apparatus; 

FIG. 4 is an explanatory view of a header in a TS 

packet; 

FIG. 5 is an explanatory view of an RTP header; 

FIG. 6 is an explanatory view of a UDP header; 

FIG. 7 is an explanatory view of an IP header; 

FIG. 8 is an explanatory view of a MAC header; 

FIG. 9 is a block diagram showing a typical 
internal structure of a receiver apparatus; 

FIG. 10 is an explanatory view of data stored in a 
storage unit; 

FIG. 11 is an explanatory view of a packet 
structure ; 

FIG. 12 is an explanatory view of another packet 
structure ; 

FIG. 13 is a flowchart of steps constituting a 
redundancy process; 

FIGS . 14A and 14B are explanatory views of other 
packet structures ; 

FIG. 15 is an explanatory view of another packet 
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structure ; 

FIG. 16 is an explanatory view of another packet 
structure ; 

FIG. 17 is a flowchart of steps constituting a 
storage process; and 

FIG. 18 is an explanatory view showing recording 
media that may be used. 

Best Mode for Carrying out the Invention 

Preferred embodiments of the present invention will 
now be described with reference to the accompanying 
drawings. FIG. 1 is a schematic view showing a typical 
structure of a sending- receiving system practiced as an 
embodiment of the invention. The sending- receiving system 
of FIG. 1 is made up of a sender apparatus 1 and a 
receiver apparatus 2 . The sender apparatus 1 receives TV 
broadcast data via an antenna 3 and transmits the 
received data to the receiver apparatus 2 . The receiver 
apparatus 2 has presentation equipment (e.g., a display 
unit) and an audio output device (e.g., speakers) whereby 
images and sounds derived from the received data are 
output . 

It is assumed here that analog- signal TV broadcasts 
are received and the data representative of the received 
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broadcasts is sent to the receiver apparatus 2. However, 
this is not limitative of the invention. The present 
invention applies not only to analog- signal TV broadcasts 
but also to digital-signal TV broadcasts such as BS 
(broadcasting satellite) digital broadcasts, CS 
(communications satellite) digital broadcasts, and 
terrestrial digital broadcasts. 

It is also possible to attach devices such as a VTR 
(video tape recorder) and a DVD (digital versatile disc) 
player to the sender apparatus 1 so that data coming from 
the attached devices may be transmitted and received. 
Furthermore, the sender apparatus 1 may be connected to a 
network such as the Internet and the information acquired 
over the connected network may also be transmitted and 
received . 

The sender apparatus 1 and receiver apparatus 2 
transmit and receive data wirelessly. The wireless 
communication takes place illustratively in accordance 
with IEEE 802.11. For example, a user may set up the 
sender apparatus 1 fixedly somewhere in his or her 
household while bringing the receiver apparatus 2 to a 
desired place in the house to watch TV broadcasts. 

FIG. 2 shows a typical internal structure of the 
sender apparatus 1. The internal structure illustrated in 
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FIG. 2 indicates major components that need to be 
explained in connection with this invention. The 
components irrelevant to the invention are not shown, 
such as a tuner for extracting user-designated programs 
from received TV broadcasts or a switcher for switching 
inputs from the VTR, DVD player and the like attached to 
the sender apparatus 1 . 

The sender apparatus 1 inputs data (signal) 
representative of the TV broadcasts received via the 
antenna 3. The input signal is illustratively an analog 
signal that is introduced into an MPEG (Moving Picture 
Experts Group) encoder 21. In turn, the MPEG encoder 21 
converts the input analog signal into digital data in 
MPEG- compressed format . 

Where digital -signal TV broadcast data is input, 
there is no need to encode the data using the MPEG 
encoder 21. That means the apparatus need not be 
structured to let all input data pass through the MPEG 
encoder 21; there may be provided different ports through 
which to input different types of data. In that case, the 
sender apparatus 1 may be equipped with a switcher, not 
shown, for selecting the output destination to which to 
forward the input data. 

The output from the MPEG encoder 21 is in transport 
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stream (called TS) packet form and is supplied to an RTP 
(Real Time Protocol) header supplementing unit 22. The 
RTP header supplementing unit 22 puts a predetermined 
number (e.g., seven) of the supplied TS packets together 
and supplements the grouped packets (called a TS packet 
sequence) with an RTP header. The packet sequence 
together with its header is sent to a UDP (User Datagram 
Protocol) header supplementing unit 23. The TS packet 
sequence supplemented with the RTP header by the RTP 
header supplementing unit 22 may be called an RTP packet. 

The UDP header supplementing unit 23 further 
supplements the supplied RTP packet with a UDP header, 
before sending the packet along with the header to an IP 
(Internet Protocol) header supplementing unit 24. The RTP 
packet supplemented with the UDP header by the UDP header 
supplementing unit 23 may be called a UDP packet. 

The IP header supplementing unit 24 supplements the 
supplied UDP packet with an IP header and forwards the 
packet together with the header to a MAC (Media Access 
Control) header supplementing unit 25. The UDP packet 
supplemented with the IP header by the IP header 
supplementing unit 24 may be called an IP packet. 

The MAC header supplementing unit 25 supplements 
the supplied IP packet with a MAC header and sends the 
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packet along with the header to a communication unit 26. 
The IP packet supplemented with the MAC header by the MAC 
header supplementing unit 25 may be called a MAC packet . 

The TS packets supplemented with the different 
headers at the different stages and turned into the MAC 
packet as described above are transmitted from the 
communication unit 26 to the receiver apparatus 2. 

A redundancy control unit 27, to be discussed later 
in more detail, is provided to exert control such that 
predetermined data (e.g., audio data) is transmitted a 
plurality of number of times (i.e., target data is made 
redundant (multiplexed) when transmitted) . The redundancy 
control unit 27 causes a storage unit 28 to supply 
packets to the UDP header supplementing unit 23 as needed. 
Furthermore, the redundancy control unit 27 causes the 
storage unit 2 8 to store the RTP packets coming from the 
RTP header supplementing unit 22 . 

The storage unit 28 accommodates the predetermined 
data to be transmitted a plurality of number of times in 
order to make the redundant data transmission possible. 
Also stored in the storage unit 28 is an RTP header 
corresponding to the predetermined data to be sent. 

FIG. 3 is an explanatory view of typical data (MAC 
packet) that is fed to the communication unit 2 6 after 
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undergoing the processing by a series of components 
ranging from the MPEG encoder 21 to the MAC header 
supplementing unit 25. As shown in FIG. 3, the data 
supplied to the communication unit 2 6 includes a TS 
packet sequence 41 encoded by the MPEG encoder 21. As 
mentioned above, seven TS packets 51-1 through 51-7 
constitute a TS packet sequence 41 included in a MAC 
packet sent to the communication unit 26. Each TS packet 
is made up of 188 bytes. 

A single TS packet 51-1 in the TS packet sequence 
41 is formed by a header part 61 and a data part 62. The 
header part 61 includes data such as that shown in FIG. 4. 
The data part 61 includes video or audio data to be 
offered to the user by the receiver apparatus 2 (FIG. 1) 
as images or sounds . 

FIG. 4 shows a typical data structure of the header 
part 61 in the TS packet 51. The header part 61 is 
constituted by 4 bytes and the data part 62 by 184 bytes. 
A "sync byte" field in the header part 61 serves to 
provide synchronization and its value is fixed 
illustratively at 47h. An "error flag" is a flag that 
indicates whether there exists any uncorrectable bit 
error in the TS packet 51. 

A "start flag" indicates that this packet is a new 
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PES packet or a new TS-PSI section. A "priority flag" 
indicates the priority of this packet. If the priority 
flag bit is set for 1, that means the priority of this 
packet is higher than the other TS packets 51. A "PID" 
field constitutes a 13 -bit numeric value (identifier) 
indicating whether a payload part (i.e., data part 62) of 
the TS packet 51 has video data, audio data, TS-PSI (TS- 
program specific information), or something else. 

A "scrambling mode" field has information denoting 
the scrambling mode of the data part 62. An "adaptation 
field flag" is a flag that provides information 
indicating the presence or absence of an adaptation field 
containing PCR (program clock reference) or like 
information. A "continuity counter" field has a counter 
value incremented by 1 for each packet having the same 
PID. 

The MPEG encoder 21 (FIG. 2) converts the input 
analog signal into digital data. The digital data is then 
subjected to MPEG compression so as to generate the data 
part 62 and header part 61 shown in FIG. 4, whereby a 
single TS packet 51 is created. 

FIG. 3 shows a TS packet sequence 41 made up of 
seven such TS packets 51. An RTP header 42 (FIG. 3) 
supplemented by the RTP header supplementing unit 22 (FIG. 
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2) has a data structure such as that shown in FIG. 5. 

Reference character "V" in the RTP header 4 2 
represents a version bit, i.e., information indicating 
the version number of the format in which the RTP header 
42 is furnished. Reference character "P" denotes a 
padding bit used to adjust the size of this packet. 
Reference character "X" stands for an extension bit 
designated at function extension time. 

Reference characters W CC" represent a CSRC count, 
i.e., information indicating the number of transmission 
sources involved in a real-time transmission process. 
Reference character W M" denotes a marker bit delimiting a 
frame boundary of each packet. Reference characters "PT" 
stand for a payload type constituting information about 
the type of the payload in effect. A "sequence number" 
field has information indicating the sequence number of 
the RTP packet in terms of packet sequence. 

A "time stamp" field gives information about the 
time stamp at which the RTP header 42 was created. An 
"SSRC" field constitutes a synchronization source 
identifier indicating a synchronization source, i.e., the 
source of the first transmission. A "CSRC" field has 
contributing source identifiers that identify the 
destinations (clients) to which to transmit the group of 
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packets included in a message. 

The TS packet sequence 41 is inserted into the 
payload corresponding to the RTP header 4 2 having the 
above-mentioned items of information. The RTP packet 
furnished with the RTP header 4 2 above is further 
supplemented with a UDP header 4 3 (FIG. 3) by the UDP 
header supplementing unit 23 (FIG. 2) . 

FIG. 6 shows a typical data structure of the UDP 
header 43. An "SRC port" field in the UDP header 43 has 
information designating the port number of the 
transmission source. A "DEST port" field has information 
designating the port number of the destination to which 
to send data. The two fields provide information for 
designating the services to be used. 

A " length" field has information indicating the 
combined length of the UDP header 4 3 and of the data 
subsequent to it (in bytes) . A "checksum" field has 
information constituting a value calculated on the basis 
of the UDP header information and the data length. The 
receiving side does the same calculations as the sender 
side to calculate the checksum. A check is then made to 
determine whether or not the calculated value matches the 
checksum included in the received UDP header 43 . A 
checksum mismatch indicates the possibility of the packet 
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having been destroyed in transmit. 

The UDP packet furnished with the UDP header 4 3 
above is further supplemented with the IP header 44 (FIG. 
3) by the IP header supplementing unit 24 (FIG. 2) . FIG. 
7 shows a typical data structure of the IP header 44. The 
data structure of the IP header 44 in FIG. 7 indicates 
only basic header fields; no optional header fields are 
shown. 

A "ver" field has information indicating the 
version of the Internet Protocol (IP) in use. An "IHL" 
field has information indicating an Internet header 
length, i.e., the length of this header. A "TOS" field 
gives information about the type of service, defining the 
priority of data and designating the type of transfers to 
be made . 

A "TL" field gives information indicating a Total 
length, i.e., the combined length of the IP header 44 and 
of the data subsequent to it. An "ID" field has 
information identifying the IP packet indicated by the IP 
header 44. An U FL" field has information about control on 
the fragmentation of data in the IP layer. 

An "FO" field gives information indicating where 
data is located upon its fragmentation in the IP layer. A 
"TTL" field gives information indicating the time to live, 
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i.e., a time period that ends upon discarding of the data 
including this IP header 44. A "PROT" field has 
information indicating the protocol for use in layers 
above the IP layer. 

An "HC" field gives information constituting a 
checksum allowing the receiving side to determine whether 
the IP header 44 has been destroyed during transmission. 
An "SA" field gives information indicating the IP address 
of the source from which data was transmitted. A "DA" 
field gives information indicating the IP address of the 
destination to which to transmit data. 

The IP packet furnished with the IP header 44 above 
is supplemented with a MAC header 4 5 (FIG. 3) by the MAC 
header supplementing unit 2 5 (FIG. 2) . FIG. 8 shows a 
typical data structure of the MAC header 45. 

A "PA" field provides preamble information used to 
lock PLL for clock recovery. A "DA" field has information 
indicating the MAC address of a transmission destination. 
An "SA" field gives information indicating the MAC 
address of a transmission source. A "type" field gives 
information indicating the protocol of an upper layer. 

A "length" field has information indicating the 
number of bytes that make up the payload. One MAC header 
45 carries either the "type" or the "length" information. 
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An "FCS" field provides information for error checks. The 
data shown in FIG. 3 (i.e., MAC packet) is created with 
the addition of the MAC header 4 5 including the 
information described above. 

For convenience of explanation, it is assumed here 
that the data having the structure shown in FIG. 3 is 
transmitted from the sender apparatus 1 to the receiver 
apparatus 2. Although data with its structure excluding 
the RTP header 42 can also be sent to the receiver 
apparatus 2, this embodiment of * the invention assumes 
that data furnished with the RTP header 4 2 is transmitted 
in the format illustrated in FIG. 3. 

Transmission of data supplemented with the RTP 
header 4 2 is a precondition under which the embodiment of 
this invention implements one of its features. That is, 
predetermined data (packet) is to be sent a plurality of 
number of times through the use of information within the 
RTP header 42 (more specifically, the "sequence number" 
shown in FIG. 5 is used) . 

The UDP header 4 3 could be replaced by a TCP 
(Transmission Control Protocol) header. However, the 
embodiment of this invention opts to utilize the UDP 
header 4 3 shown in FIG. 3. 

The outgoing data is supplemented not with the TCP 
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header but with the UDP header for the following reason: 
The TCP header is furnished when TCP is utilized as the 
transport layer protocol, whereas the UDP header is 
provided when UDP is employed as the transport layer 
protocol . 

Whether TCP or UDP is to be used as the transport 
layer protocol depends in part on what kind of data is 
transmitted and received during communication processes 
pursuant to the protocol- TCP may be called a connection 
type protocol and UDP a connectionless type protocol. 

Being a connection type protocol, TCP requires 
complicated procedures in processing data exchanges but 
ensures higher degrees of reliability during 
communication processes. As such, TCP is employed 
primarily for communications that give priority to 
dependability. As opposed to TCP, UDP as a connectionless 
type protocol entails much simplified procedures in 
processing data exchanges while reducing the time 
required for communication. That is, UDP is utilized 
principally for communications that give priority to 
processing speed. 

With this embodiment of the invention, TV broadcast 
data received by the sender apparatus 1 is transmitted to 
the receiver apparatus 2 as mentioned above. For that 
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reason, UDP is adopted as the protocol giving priority to 
processing speed rather than to the reliability in real- 
time data exchanges . 

During communication processes under UDP, however, 
the sender apparatus 1 keeps transmitting data 
successively whether or not the data is being actually 
received by the receiver apparatus 2. The receiver 
apparatus 2 could fail to receive some of the data that 
is being sent continuously. If the receiver apparatus 2 
proceeds with its processing without acquiring the 
missing data, the images or sounds offered to the user 
could be interrupted or otherwise disturbed. These 
irregularities should be avoided if at all possible. 

With this embodiment of the invention, even if UDP 
is adopted as the protocol giving priority in real-time 
data exchanges, the receiving side is arranged to recover 
the data that has been lost somehow in transmit during 
communication under UDP. During the data recovering 
process, the sender and the receiver sides are prevented 
from being overloaded through inventive arrangements. 

What follows is a description of a receiver 
apparatus 2 having the above-mentioned capability to 
acquire the missing data from the sender apparatus 1 
whose structure is shown in FIG. 2. FIG. 9 shows a 
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typical internal structure of the receiver apparatus 2. A 
communication unit 81 of the receiver apparatus 2 
receives data from the sender apparatus 1. The data 
received by the communication unit 81 from the sender 
apparatus 1, structured as shown in FIG. 3, is fed to a 
MAC header extraction unit 82. The MAC header extraction 
unit 82 extracts a MAC header 4 5 (FIG. 3) from the 
supplied data (i.e., MAC packet) and forwards the 
resulting IP packet devoid of the MAC header to an IP 
header extraction unit 83 . 

The IP header extraction unit 83 extracts an IP 
header 44 from the supplied IP packet and sends the 
resulting UDP packet to a UDP header extraction unit 84 . 
The UDP header extraction unit 83 extracts a UDP header 
43 from the supplied UDP packet and supplies the 
resulting RTP packet to a sequence reconstitution unit 85. 

The sequence reconstitution unit 8 5 references the 
"sequence number" field (FIG. 5) in the RTP header 42. 
The sequence numbers are generally serial numbers 
assigned in ascending order to packets (i.e., RTP headers 
42), i.e., in the order in which the packets were 
processed by the sender apparatus 1. Alternatively, the 
sequence numbers may be assigned in descending order to 
the packets . 
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The sequence reconstitution unit 85 references the 
sequence number in the supplied RTP packet and determines 
whether a storage unit 8 7 holds the data having the same 
number as the referenced sequence number (i.e., 
corresponding data) . If the corresponding data is found 
to exist in the storage unit 87, the sequence 
reconstitution unit 85 discards the supplied RTP packet. 
If the corresponding data is not found in the storage 
unit 87, the sequence reconstitution unit 8 5 forwards the 
supplied RTP packet to an RTP header extraction unit 86. 

The RTP header extraction unit 8 6 extracts the RTP 
header 4 2 from the supplied RTP packet and stores the 
resulting TS packet sequence 41 into the storage unit 87. 
The TS packet sequence 41 thus placed into the storage 
unit 87 is stored in conjunction with the sequence number 
included in the RTP header 42. 

The storage unit 8 7 usually accommodates one TS 
packet sequence 41, i.e., seven TS packets 51. In case of 
an error, less than seven TS packets 51 may be found in 
the storage unit 87. 

The storage unit 87 serves as a buffer that outputs 
the TS packets 51 successively to an MPEG decoder 88. The 
MPEG decoder 8 8 decodes the successively supplied TS 
packets 51 in accordance with the MPEG standard. The 
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output from the MPEG decoder 8 8 is fed to a display unit 
and speakers, not shown, as images and sounds offered to 
the user. 

What follows is an explanation of the data held in 
the storage unit 87. FIG. 10 is an explanatory view 
depicting a typical structure of the data stored in the 
storage unit 87. In the storage unit 87, as mentioned 
above, the sequence number included in the RTP header 42 
is stored in conjunction with the TS packets contained in 
that RTP packet corresponding to the sequence number. 

The sequence numbers held in the storage unit 8 7 
may be either the sequence numbers themselves or some 
suitable data uniquely representative of these sequence 
numbers . 

Illustratively, as shown in FIG. 10, sequence 
number u l" is stored in conjunction with TS packets 51-1- 
1 through 51-7-1 (the last digit of the reference numeral 
for each packet denotes a sequence number (hence the same 
numeral) ) . That is because the embodiment of this 
invention assumes that each RTP packet (i.e., MAC packet 
received by the receiver apparatus 2) includes seven TS 
packets 51-1 through 51-7 (FIG, 3) . If eight TS packets 
were assumed to be included in one RTP packet, then 
sequence number w l" would be stored in association with 
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eight TS packets 51-1-1 through 51-8-1. 

Referring again to FIG. 10, sequence number "2" is 
stored likewise in conjunction with seven TS packets 51- 
1-2 through 51-7-2. Sequence number "3," however, has no 
TS packets stored in connection therewith in the example 
of FIG. 10 although TS packets 51-1-3 through 51-7-3 
would be thought of by association. Sequence number "4" 
is held in conjunction with TS packets 51-1-4 through 51- 
7-4 . 

As described, the TS packets 51 (as the TS packet 
sequence 41) that have been received and processed 
normally are stored in suitable areas in the storage unit 
87 in conjunction with the corresponding sequence number. 
That is, the TS packets are stored in the order in which 
their sequence numbers occur in series . If for some 
reason any TS packets have not been received normally, 
nothing is stored in connection with the corresponding 
sequence number (e.g., the area associated with sequence 
number "3" has no packets stored in FIG. 10) . 

In the storage unit 87, as described, the sequence 
numbers related to the areas having TS packets stored 
therein coexist with the sequence numbers corresponding 
to the areas with no packets stored. In such a setup, it 
is possible to distinguish the sequence numbers regarding 
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the areas in which TS packets are stored, from the 
sequence numbers regarding the areas without TS packets, 
through the use of a flag indicating the presence or 
absence of TS packets. That flag may also be used in 
processes to be discussed later, 

What follows is a description of how the sender 
apparatus 1 (its structure shown in FIG. 2) and receiver 
apparatus 2 (its structure in FIG. 9) operate in 
transmitting and receiving the data explained above with 
reference to FIGS. 3 through 8. How the sender apparatus 
1 functions is described first. 

The sender apparatus 1 supplements TV broadcast 
data received via the antenna 3 with headers before 
sending the header- furnished data to the receiver 
apparatus 2 . A predetermined part of the transmitted data 
is sent a plurality of times (e.g., twice here, for 
purposes of description) . The manner in which that part 
of the data is sent every time is explained below. 

The TV broadcast data received by the antenna 3 is 
encoded by the MPEG encoder 21 based on the MPEG standard. 
The encoded data is output as TS packets 51 to the RTP 
header supplementing unit 22. The RTP header 
supplementing unit 22 turns every seven input TS packets 
51 into a TS packet sequence 41, and supplements the TS 
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packet sequence 41 thus generated with an RTP header 42. 

The RTP packet supplemented with the RTP header 4 2 
is fed to the UDP header supplementing unit 23 and 
redundancy control unit 27. Below is an explanation of 
the RTP packet supplied to the UDP header supplementing 
unit 23 and redundancy control unit 27. FIGS. 11 and 12 
schematically show typical structures of the RTP packet. 

FIG. 11 shows a structure of an RTP packet formed 
by a TS packet sequence 101 supplemented with an RTP 
header 102. The TS packet sequence 101 in the RTP packet 
of FIG. 11 is made up of video data parts 104-1 through 
104-7 supplemented with headers 103-1 through 103-7 
respectively. The headers 103-1 through 103-7 contain the 
data fields such as those shown in the header part 61 of 
FIG. 4. Of these data fields, the "PID" field is set for 
"lOOh" in this example. 

As described above with reference to FIG. 4, the 
value of the "PID" field in the header part 61 is 
determined in a manner which is dependent on the data in 
the data part 62 following the header part 61. If the 
data part 62 has video data, then the PID value is 
assumed to be u 100h" ; if the data part 62 has audio data, 
the PID value is assumed to be u 102h." 

The PID values may be any values as long as they 
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can be distinguished between the sender apparatus 1 and 
the receiver apparatus 2 . These values are set by the 
MPEG encoder 21. Since the data parts 62 in the TS 
packets constituting the TS packet sequence 101 of FIG. 

11 contain only video data, the "PID" fields in the 
headers 103-1 through 103-7 are all set for "lOOh." 

By contrast, a TS packet sequence 111 shown in FIG. 

12 contains an audio data part 114-3. A header 113-3 
attached to the audio data part 114-3 has its PID value 
set for "102h." 

Video data usually occurs in larger quantity than 
concomitant audio data. For that reason, it is generally 
the case that the TS packet sequence 101 either contains 
only video data packets as shown in FIG. 11, or includes 
one or a few audio data packets among the TS packets 
making up the TS packet sequence 111 as indicated in FIG. 
12 . 

The "sequence number" field in the RTP packet of 
FIG. 11 is assigned a value of "1234h." If the RTP packet 
of FIG. 12 is generated immediately after the RTP packet 
of FIG. 11, then the "sequence number" field in an RTP 
header 112 of the RTP packet in FIG. 12 is assigned a 
value of u 1235h," a serial number continuous to the 
preceding value "1234h." 
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An RTP packet formed solely by video data parts as 
shown in FIG. 11, or an RTP packet constituted by video 
and audio data parts as indicated in FIG. 12 , is 
generated by the RTP header supplementing unit 22. The 
generated RTP packet is supplied to the UDP header 
supplementing unit 23 and redundancy control unit 27. The 
UDP header supplementing unit 23 supplements the supplied 
RTP packet with a UDP header and forwards the UDP header- 
furnished packet to the IP header supplementing unit 24 . 
The IP header supplementing unit 24 supplements the 
received UDP packet with an IP header before sending the 
IP header- furnished packet to the MAC header 
supplementing unit 25. 

The MAC header supplementing unit 25 supplements 
the received IP packet with a MAC header and feeds the 
MAC header- furnished packet to the communication unit 26. 
Given the MAC packet, the communication unit 26 executes 
a first transmission of the supplied packet to the 
receiver apparatus 2. 

How the sender apparatus 1 performs a second 
transmission of the packet will now be described by 
referring to the flowchart of FIG. 13. The steps outlined 
in FIG. 13 are carried out primarily by the redundancy 
control unit 27. The process constituted by the steps in 
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FIG. 13 is executed on each RTP packet output by the RTP 
header supplementing unit 22. For the flowchart of FIG. 
13, it is assumed that only audio data is subject to the 
second transmission . 

In step Sll, the redundancy control unit 27 checks 
to determine whether or not the RTP packet coming from 
the RTP header supplementing unit 2 2 includes audio data. 
The result of the check in step Sll is negative (NO) if 
the RTP packet supplied to the redundancy control unit 27 
includes the TS packet sequence 101 constituted solely by 
the video data parts 104-1 through 104-7 as shown in FIG. 
11. 

If the RTP packet sent to the redundancy control 
unit 27 includes the TS packet sequence 111 containing 
the audio data part 114-3 as indicated in FIG. 12, then 
the result of the check in step Sll is affirmative (YES) . 

The redundancy control unit 27 determines whether 
or not audio data is included in the supplied RTP packet 
by referencing the "PID" field in the header of each of 
the TS packets involved. A TS packet whose "PID" field is 
set for "10 Oh" is deemed to have video data; a TS packet 
with its "PID" field set for "102h" is deemed to have 
audio data. 

If in step Sll the redundancy control unit 2 7 
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determines that the supplied RTP packet does not include 
any audio data, then the unit 2 7 discards the RTP packet 
and terminates the process (of the flowchart in FIG. 13) 
on the RTP packet in question. 

If in step Sll the redundancy control unit 27 
determines that the supplied RTP packet includes audio 
data, then step S12 is reached. In step S12, the 
redundancy control unit 2 7 extracts the RTP header and 
the audio data part (i.e., the TS packet containing the 
audio data) from the supplied RTP packet and stores what 
is extracted into the storage unit 28. 

What takes place in steps Sll and S12 is explained 
below in more detail with reference to FIGS. 14A and 14B. 
FIG. 14A shows the same RTP packet as that in FIG. 12. 
The TS packet sequence 111 in the RTP packet of FIG. 14A 
includes the audio data part 114-3 (with the header 113-3 
having its "PID" field set for u 102h"). The sequence 
number of the RTP header 112 for the TS packet sequence 
111 containing the audio data part 114-3 is set for 
"1235h." 

Where the audio data part 114-3 is included in the 
RTP packet as described above, the storage unit 28 
receives and accommodates the supplied RTP header 112, 
audio data part 114-3, and the header 113-3 attached to 

34 



S04P0344 



the audio data part 114-3. 

Upon storage into the storage unit 28, a TS packet 
sequence 121 is generated which contains only the audio 
data part 114-3 and header 113-3, supplemented with the 
RTP header 112 . 

The redundancy control unit 2 7 may generate the RTP 
packet of FIG. 14B from the RTP packet of FIG. 14A either 
by eliminating the unnecessary data (i.e., the video data 
parts and the headers attached to them) , or by extracting 
the necessary data (i.e., the audio data part and the 
header attached to it) . 

After the RTP packet containing the audio data 
alone is stored into the storage unit 28 as described, 
step S13 is reached. In step S13, the redundancy control 
unit 2 7 checks to determine whether a predetermined 
number of RTP packets have been output (i.e., supplied). 
The redundancy control unit 27 may carry out the check of 
step S13 by counting the number of supplied RTP packets. 

Alternatively, the redundancy control unit 27 may 
perform the check of step S13 by referencing the sequence 
number in the RTP header 42 of each RTP packet. For 
example, a predetermined value may be added to the 
sequence number of the RTP packet stored in the storage 
unit 28. The check of step S13 is then executed by 
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determining whether the RTP packet containing the 
sequence number derived from the addition is supplied. 

If in step S13 the redundancy control unit 27 finds 
that the predetermined number of RTP packets have been 
supplied, step S14 is reached. It should be noted that 
even as the check of step S13 is being carried out, the 
process of the flowchart in FIG. 13 is continued on the 
RTP packet fed to the redundancy control unit 27. 

In step S14, the RTP packet including the TS packet 
sequence containing the audio data alone is retrieved 
from the storage unit 28 in which the RTP packet in 
question was stored earlier in step S12 . In this case, 
the TS packet sequence 121 and the RTP header 112 
attached to it as shown in FIG. 14B are retrieved from 
storage . 

The retrieved RTP packet is sent to the UDP header 
supplementing unit 23. After the RTP packet is supplied 
to the UDP header supplementing unit 23, the same process 
as the first- time transmission takes place. 

That is, in step S15, the RTP packet acquired from 
the storage unit 2 8 is supplemented with headers by the 
UDP header supplementing unit 23, IP header supplementing 
unit 24, and MAC header supplementing unit 25. In step 
S16, the MAC packet is transmitted to the receiver 
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apparatus 2 by the communication unit 26. 

The second transmission is carried out as described 
above. In this example, the first transmission of the 
data including the RTP packet of FIG. 12 (MAC packet) is 
followed by the second transmission of the data including 
the RTP packet of FIG. 14B. Thus the audio data part 114- 
3 is transmitted twice to the receiver apparatus 2. 

With this embodiment of the invention, the same 
audio data is sent twice to the receiver apparatus 2 as 
described. Alternatively, the same data may be 
transmitted three times or more. Specifically, steps S13 
through S16 may be carried out as many times as needed on 
one RTP packet held in the storage unit 2 8 for repeated 
transmissions . 

The same audio data is transmitted a plurality of 
number of times for the following reasons: communications 
are performed wirelessly between the sender apparatus 1 
and the receiver apparatus 2. Generally, wireless 
communications are not as stable as communications over 
wires. Obstructions coming between the sender apparatus 1 
and the receiver apparatus 2 can deteriorate the status 
of communication therebetween. The unstable communication 
can even result in the inability of the receiver 
apparatus 2 to receive the transmitted data. 
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Video data, even with some of its portions gone 
missing, rarely causes image interruptions in the video 
being offered to the user because the data is processed 
during decoding so as to compensate for data dropouts . By- 
contrast, audio data, with some of its portions lost, is 
likely to trigger sound interruptions in the audio being 
offered to the user even after a compensatory process 
similar to the one performed on video data is carried out. 

Audio data is thus more likely to exert adverse 
effects on the ongoing data reproduction than video data 
when data dropouts take place. For that reason, this 
embodiment of the invention is arranged to transmit audio 
data alone a plurality of number of times. Another reason 
for repeatedly transmitting audio data alone is related - 
to different types of data occurring in different 
quantities . 

More specifically, video data as it generally 
occurs is greater in quantity than the audio data 
occurring concomitantly. If the video data were to be 
transmitted a plurality of number of times, i.e., if all 
data were to be transmitted twice or more, the 
transmitting capacity of the sender apparatus 1 or the 
receiving capacity of the receiver apparatus 2, or both, 
might be overwhelmed when the apparatuses attempt to 
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carry out the repeated operations. 

In other words, if the transmitting capacity of the 
sender apparatus 1 and the receiving capacity of the 
receiver apparatus 2 are large enough to deal with the 
repeated handling of all data, then the two apparatuses 
may be arranged to transmit and receive all data in 
repetitive fashion . 

All data transmission at a plurality of number of 
times implemented as follows: all RTP packets may be 
temporally stored in the storage unit 2 8 without 
implementing the determination at step Sll and the 
subsequent processes are implemented. 

If all data is to be transmitted a plurality of 
number of times, the MAC packet instead of the RTP packet 
may be stored into the storage unit 28. That is, the 
sender apparatus 1 may be structured in such a manner 
that the storage unit 28 accommodates the MAC packet 
coming from the MAC header supplementing unit 2 5 and that 
the stored MAC packet is then output to the communication 
unit 26. 

The description will be resumed hereunder on the 
assumption that audio data alone is transmitted a 
plurality of number of times (e.g., twice). 

As described, the same audio data is transmitted at 
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least twice by the sender apparatus 1 . Following the 
first transmission (performed in a normally timed manner) , 
the timing for the second transmission (i.e., when to 
transmit the data again for redundancy) is determined 
(controlled) in step S13 (of FIG. 13) . 

FIG. 15 shows an RTP packet structure in effect 
when a second transmission is performed immediately after 
the first transmission. For the ensuing explanation, it 
is assumed that the RTP packet of FIG. 12 is sent 
following transmission of the RTP packet of FIG. 11 (i.e., 
after the redundancy control unit 2 7 has performed its 
process) . 

The RTP header 102 of the RTP packet shown in FIG. 
11 has the sequence number "1234h" . This RTP header 102 
is attached to the TS packet sequence 101. What is sent 
(i.e., processed) next is the RTP packet shown in FIG. 12. 
It follows that the RTP header 112 of the next RTP packet 
has the sequence number u 123 5h" and that the RTP header 
112 is attached to the TS packet sequence 111. 

The RTP packet of FIG. 12 contains audio data, so 
that the RTP packet shown in FIG. 14B is stored into the 
storage unit 2 8 under control of the redundancy control 
unit 27. The stored RTP packet, i.e., the TS packet 
sequence 121 prefixed with the RTP header 112, is 
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arranged to be sent immediately following the TS packet 
sequence 111 as illustrated in FIG. 15. 

Of the RTP headers shown in FIG. 15, the RTP 
headers 112 having the same sequence number "123 5h" are 
transmitted continuously. In such a case, step S13 in the 
flowchart of FIG. 13 need not be carried out . That is, 
the RTP packet held in the storage unit 28 need only be 
forwarded to the UDP header supplementing unit 2 3 
immediately after the RTP packet having the same sequence 
number has been output by the UDP header supplementing 
unit 23 . 

However, it is prudent to assume that the situation 
where the incoming data cannot be received by the 
receiver apparatus 2 for some reason, i.e., a state in 
which packets have gone missing, will not be improved in 
a short time. In other words, in a situation where 
packets tend to drop out, not one packet but a plurality 
of packets will likely drop out in a row. On the basis of 
past experience, when packets start to drop out, 10 to 15 
RTP packets are likely to go missing consecutively. 

Under such circumstances , the repeated 
transmissions of audio data to compensate for packet 
dropouts can be meaningless unless they are properly 
timed. 
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Referring again to FIG. 15, if an RTP packet 
prefixed with the RTP header 112 goes missing and another 
RTP packet prefixed with the same RTP header 112 is sent 
immediately thereafter, it is highly likely that the 
second RTP packet will also be lost in transit. When the 
compensatory packets tend to be lost as well, the 
repeated transmissions of the same data will have little 
meaning . 

In other words, where at least audio data is to be 
sent twice to counter possible packet dropouts, it may be 
more effective to make the second transmission, say, 15 
RTP packets after the first transmission. When a 
predetermined interval is interposed between the first 
and the second transmissions, even if an RTP packet sent 
first has gone missing, the same RTP packet transmitted a 
second time will likely be received normally. 

Step S13 (of FIG. 13) is provided in view of such 
eventualities. Step S13 may be carried out illustratively 
by the redundancy control unit 27 checking to determine 
whether or not a predetermined number (e.g., 15) of RTP 
packets have been supplied. 

FIG. 16 shows an RTP packet structure in effect 
when a second transmission of an RTP packet takes place 
after a predetermined number of RTP packets were 
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transmitted earlier. Of the RTP headers shown in FIG. 16, 
those with reference numerals 102, 112 and 132 have 
sequence numbers that are serially continuous. That is, 
the packet sequences prefixed with these headers are 
transmitted in the order in which they have been 
processed. 

After the predetermined number of RTP packets have 
been transmitted, the RTP header 112 with the sequence 
number u 1235h" is sent again. Even if the RTP header 112 
(i.e., TS packet sequence 111) immediately following 
transmission of the RTP header 102 has gone missing for 
some reason, the same RTP header 112 (i.e., TS packet 
sequence 121) is more likely to be received normally 
thanks to the communication state supposedly improved 
over time. 

If at least one of the packets handled in the first 
and the second transmissions can be received, that means 
there is practically no audio data dropout. This 
arrangement forestalls irregularities such as sound 
disconnections in the audio being offered to the user. 

Below is a description of how the receiver 
apparatus 2 receives and handles predetermined data being 
transmitted a plurality of number of times. FIG. 17 is a 
flowchart of steps in which the receiver apparatus 2 
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typically operates. In step S31, the data (MAC packet) 
sent from the sender apparatus 1 and received by the 
communication unit 81 (FIG. 9) is supplied to the MAC 
header extraction unit 82. 

The MAC header extraction unit 82 extracts the MAC 
header 4 5 from the supplied MAC packet and forwards the 
resulting IP packet to the IP header extraction unit 83. 
The IP header extraction unit 83 extracts the IP header 
44 from the supplied IP packet and sends the resulting 
UDP packet to the UDP header extraction unit 84. The UDP 
header extraction unit 84 extracts the UDP header 4 3 from 
the supplied UDP packet and feeds the resulting RTP 
packet to the sequence reconstitution unit 85. 

As described, the headers are removed from the 
supplied data successively by the relevant components. 
These components handle the extracted headers in their 
own ways which, however, are not directly relevant to 
this invention and thus will not be discussed further. 

In step S32, the sequence reconstitution unit 85 
references the RTP header 42 in the supplied RTP packet. 
What is referenced at this point is the sequence number 
inside the RTP header 42. In step S33, the sequence 
reconstitution unit 85 references the storage unit 87 to 
determine whether or not the TS packets have already been 
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stored therein in conjunction with the referenced 
sequence number. 

As explained above with reference to FIG. 10, the 
storage unit 87 has a sequence number stored in 
association with a TS packet sequence 41 (FIG, 3) 
prefixed with the RTP header 4 2 having that sequence 
number. In steps S32 and S3 3, the sequence reconstitution 
unit 85 therefore references the sequence number in the 
RTP header 4 2 of the supplied RTP packet and checks to 
determines whether the TS packet sequence 41 
corresponding to the referenced sequence number is stored 
in the storage unit 87. 

If in step S33 the TS packet sequence 41 
corresponding to the sequence number held in the supplied 
RTP header 42 is not found in the storage unit 87, then 
step S34 is reached. In step S34, the sequence 
reconstitution unit 85 sends the supplied RTP packet to 
the RTP header extraction unit 86. 

The RTP header extraction unit 8 6 extracts the RTP 
header 4 2 from the supplied RTP packet and sends the 
resulting TS packet sequence 41 to the storage unit 8 7 
for storage therein. At this point, the TS packet 
sequence 41 is placed into the storage unit 87 in 
conjunction with the sequence number contained in the RTP 
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header 4 2 . 

What follows is a supplementary explanation for the 
steps up to the storage process above . There are two 
conceivable situations in which the sequence 
reconstitution unit 85 determines that the TS packet 
sequence 41 associated with the sequence number in the 
supplied RTP header 4 2 is not stored in the storage unit 
87. 

One such situation is where the new RTP packet 
(i.e., TS packet sequence 41) is supplied too early to be 
placed into the storage unit 87. The other situation is 
one in which the TS packet sequence 41 that should have 
already been received, processed and stored has yet to be 
received for some reason, that is, the TS packet sequence 
41 has gone missing, and is thus not found in the storage 
unit 87. 

In the second situation above, the sequence number 
itself is already placed in the storage unit 87. 
Referring again to FIG. 10, what is shown here is the 
state in which the TS packet sequence 41 to be stored in 
conjunction with the sequence number "3" (i.e., the TS 
packet sequence that should be made up of the TS packets 
51-1-3 through 51-7-3) seems to have dropped out and has 
yet to be placed into storage. The storage area in which 
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to place the apparently -lost packets is managed (i.e., 
allocated) in association with the corresponding sequence 
number . 

If step S34 is reached in the second situation 
above, the sequence reconstitution unit 8 5 (or the RTP 
header extraction unit 86) causes the TS packet sequence 
41 in the supplied RTP packet to be stored into an 
appropriate storage area allocated in the storage unit 87 
in conjunction with the sequence number in the RTP header 
4 2 attached to the RTP packet in question. 

That is, in the case above, the TS packet sequence 
41 received subsequently is placed into a storage area 
allocated in such a manner that its content will be sent 
to the MPEG decoder 8 8 ahead of the TS packet sequence 41 
being processed at present. 

The subsequently-received TS packet sequence 41 
(i.e., the one received in the second transmission) has 
audio data alone. Thus only the TS packets 51 containing 
the audio data are stored. If video data is to be 
transmitted a plurality of number of times as well, the 
video data will also be stored (i.e., the TS packet 
sequence 41 will be stored) . 

As described, the missing packets may be acquired 
and stored into the storage unit 87 upon receipt and 
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necessary processing following the subsequent 
retransmission. This makes it possible to avoid the 
adverse effects of packets dropping out in transit. 

Returning to step S33 in the explanation of the 
flowchart of FIG. 17, the sequence reconstitution unit 85 
checks to determine whether the TS packet sequence 41 
corresponding to the sequence number in the supplied RTP 
header 42 is already stored in the storage unit 87. If 
the corresponding TS packet sequence 41 is deemed to 
exist in the storage unit 87, step S35 is reached. 

The foregoing state is one in which both the first - 
transmitted and the second- transmitted packets have been 
normally received, processed and stored. In this case, 
there is no need to take steps to place the retransmitted 
packet into the storage unit 87. The sequence 
reconstitution unit 85 thus discards the supplied RTP 
packet in step S35. 

When the foregoing steps are carried out by the 
receiver apparatus 2, it is possible to minimize the 
adverse effects of the packet dropouts because the 
retransmitted packets are received and processed. At the 
same time, it is also possible not to appropriate an 
inordinately large portion of the available processing 
capabilities for dealing with the missing packets. 
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In the foregoing example, predetermined data was 
shown transmitted a plurality of number of times (e.g., 
twice) . In practice, it is necessary to consider putting 
constraints on the number of times the data may be 
transmitted. If the data is to be transmitted twice, it 
is necessary further to consider an appropriate time 
interval between the first and the second transmissions. 

The considerations above are needed for the 
following reasons: The TS packets held in the storage 
unit 87 are supplied consecutively to the MPEG decoder 88. 

Referring again to FIG. 10, the TS packets 51-1-1 
through 51-7-1 associated with the sequence number w l" 
are first supplied to the MPEG decoder 88. Then the TS 
packets 51-1-2 through 51-7-2 associated with the 
sequence number "2" are fed to the MPEG decoder 88. 

After that, the TS packets corresponding to the 
sequence number "3" should be supplied to the MPEG 
decoder 88. Since the corresponding TS packets are not 
found in storage when it is time for them to be fed to 
the MPEG decoder 88, they are skipped and the TS packets 
51-1-4 through 51-7-4 associated with the next sequence 
number "4" are output instead. 

In other words, if the TS packets associated with 
the sequence number "3" are not placed into the storage 
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unit 87 before the TS packets associated with the 
sequence number w 4" are timed to be fed to the MPEG 
decoder 88, there is no need subsequently to acquire the 
missing packets or to carry out steps in connection with 
the packet dropouts . 

With these things taken into account, if the same 
packet is to be sent a plurality of number of times by 
the sender apparatus 1, the number of times the packet is 
transmitted needs to be determined in consideration of 
the capacity of the storage unit 8 7 in the receiver 
apparatus 2 . 

For example, if the storage unit 87 has a capacity 
large enough to accommodate one second of packet data, 
then there is no meaning in the attempt by the sender 
apparatus 1 to send the same packet upon elapse of one 
second or longer. In that case, if the same packet is set 
to be retransmitted at intervals of 100 milliseconds 
(e.g., where the number of RTP packets processed in a 
100 -millisecond interval is predetermined for step S13 in 
FIG. 13) , then the number of times the packet is 
retransmitted may be set for nine . 

That is, a' tenth transmission, even if executed by 
the sender side and received by the receiver apparatus 2, 
results in meaningless processing. There need only be 
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provided constraints that block the tenth transmission. 
If the transmission is set to be made twice, the two 
transmissions need only be performed (i.e., completed) 
within one second. 

The number of times data is retransmitted and the 
interval between the repeated transmissions should 
preferably be established in consideration of the time 
required for the receiver apparatus 2 to store the 
received data, as well as the time required for both the 
sender and the receiver sides to handle the packet during 
transmission and reception. Such considerations should be 
added to those discussed above. 

What follows is a supplementary explanation of how 
the receiver apparatus 2 operates. Although step S33 
above (FIG. 17) was shown carried out by the sequence 
reconstitution unit 85 referencing the storage unit 87, 
this is not limitative of the invention. Alternatively, 
step S3 3 may be executed without reference to the storage 
unit 87 in a manner that will be explained below. 

Since the sequence reconstitution unit 85 
references the sequence number in the RTP header 4 2 of 
each RTP packet supplied, the unit 8 5 itself may be so 
structured as to store the referenced sequence numbers. 
With this structure, the sequence reconstitution unit 85 
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may perform step S3 3 by determining whether or not the 
sequence number included in the supplied RTP header 42 
matches one of the sequence numbers currently retained 
inside . 

With the above structure in place, the other steps 
are carried out basically in the same manner as in the 
examples explained earlier. These steps will not be 
discussed further . 

As another alternative, step S33 may be performed 
by also taking advantage of the fact that the sequence 
reconstitution unit 8 5 references the sequence number in 
each RTP header 42 supplied. In this case, the sequence 
reconstitution unit 85 may check to determine whether the 
sequence number in the supplied RTP header 42 is serially 
continuous to the sequence number in the immediately 
preceding RTP header 42. 

The sender apparatus 1 assigns sequence numbers 
illustratively in ascending order (alternatively in 
descending order) to packets which are transmitted as 
they are processed. The packets are supposed to be 
received and processed by the receiver apparatus 2 in the 
order in which they were transmitted. Any missing packet 
thus leaves the corresponding sequence number undetected. 
That is, the continuity of sequence numbers is disrupted. 
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On detecting a disruption of sequence number 
continuity, the sequence reconstitution unit 85 
calculates and holds the sequence number that should 
normally be detected in the interrupted part. When 
sensing the continuity disruption, the sequence 
reconstitution unit 85 checks to determine whether the 
sequence number in the supplied RTP header 42 matches one 
of the sequence numbers currently held inside. 

After the steps carried out as described above, the 
sequence reconstitution unit 8 5 may find that the 
sequence number in the supplied RTP header 4 2 matches one 
of the currently-held sequence numbers. That means the 
sequence reconstitution unit 8 5 has determined that the 
missing packet was retransmitted and received. In that 
case, the TS packet sequence 41 included in the supplied 
RTP packet is arranged to be stored into an appropriate 
area of the storage unit 87. 

Some alternative ways to handle the packet 
retransmitted a number of times have been discussed above. 

For the above -described embodiment of this 
invention, it is audio data that is transmitted a 
plurality of number of times for redundancy. 
Alternatively, video data may also be transmitted twice 
or more often. As another alternative, something other 
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than audio data or video data (e.g., information 
contained in the header) may be transmitted a number of 
times . 

For example, text broadcast data or EPG (Electronic 
Program Guide) data may be transmitted a plurality of 
number of times. Where particular information other than 
audio data is to be transmitted a number of times, step 
Sll of FIG. 13 may be modified to determine whether or 
not that particular information is included. The modified 
step Sll may then be followed by the same subsequent 
steps discussed above. 

The principal reason for the embodiment above to 
have audio data transmitted a plurality of number of 
times is the relatively small amount of audio data 
compared with that of the concomitant video data. The 
repeated transmissions of audio data, because of its 
limited quantity, are deemed to have only negligible 
effects on other processing. 

It is on that assumption that the above embodiment 
of the invention is structured to retransmit data whose 
amount is relatively small. It follows that this 
invention applies to setups in which not only audio data 
but any data occurring in limited quantities is 
transmitted a plurality of number of times. 
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In detecting data whose amount is small, 
arrangements may be made to predetermine the type of data 
deemed to occur in limited quantities (i.e., audio data 
in the examples above) and to see if that particular data 
is included in acquired data. Alternatively, a specific 
data amount (i.e., threshold level) may be established 
beforehand and checks may be carried out to determine if 
any data below that predetermined level is included in 
what has been acquired. 

The data detected in the procedure above may then 
be stored. The stored data may be subsequently 
transmitted a plurality of number of times. 

Where the foregoing procedure is in use, the 
repeated transmissions of data in a temporally staggered 
manner minimize adverse effects from data dropouts, such 
as disruptions in the video or audio being offered to the 
user. This makes it possible to improve the reliability 
of communication between the sender apparatus 1 and the 
receiver apparatus 2 . 

The series of steps and processes described above 
may be executed either by pieces of hardware with 
relevant capabilities or by software. For the software- 
based processing to take place, the programs constituting 
the software may be either incorporated beforehand in 
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dedicated hardware of a computer or installed upon use 
from a suitable recording medium into a general -purpose 
personal computer or like equipment capable of executing 
diverse functions based on the installed programs. 

The personal computer will now be discussed in 
brief, followed by an explanation of the recording medium. 
FIG. 18 shows a typical internal structure of a general- 
purpose personal computer. A CPU (central processing 
unit) 2 01 of the personal computer performs various 
processes in accordance with the programs held in a ROM 
(read only memory) 202. A RAM (random access memory) 203 
accommodates data and programs that may be needed by the 
CPU 201 while carrying out its processing. An 
input/output interface 205 is connected with an input 
unit 206 made up of a keyboard and a mouse. Signals that 
are input to the input unit 206 are output to the CPU 201 
through the input/output interface 205 . The input/output 
interface 205 is also connected with an output unit 207 
constituted by a display device and speakers. 

Furthermore, the input/output unit 2 05 is connected 
with a storage unit 208 composed of a hard disk drive or 
like equipment, and with a communication unit 209 that 
sends and receives data to and from external devices over 
a network such as the Internet. A drive 210 is used to 
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write and read data to and from the recording medium such 
as a magnetic disk 221, an optical disk 222, a magneto- 
optical disk 223, or a semiconductor memory 224 loaded in 
the drive . 

As shown in FIG . 18, the recording medium is 
offered to the user apart from the personal computer not 
only as a package medium constituted by the magnetic disk 
221 (including flexible disks) , optical disk 222 
(including CD-ROM (Compact Disc -Read Only Memory) and DVD 
(Digital Versatile Disc) ) , magneto-optical disk 223 
(including MD (Mini-Disc; registered trademark)), or 
semiconductor memory 224, each medium carrying the 
necessary programs; but also in the form of the ROM 202 
or the hard disk drive 31 containing the storage unit 208, 
both accommodating the programs and incorporated 
beforehand in the computer. 

In this description, the steps which are stored on 
the recording medium and which describe the programs to 
be executed represent not only the processes that are to 
be carried out in the depicted sequence (i.e., on a time 
series basis) but also processes that may be performed 
parallelly or individually. 

In this description, the term "system" refers to an 
entire configuration made up of a plurality of component 
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devices . 

Industrial Applicability 

The present invention provides arrangements for 
improving the reliability of communication. According to 
this invention, the data getting lost in transit is 
compensated so that disconnections or other disruptions 
will not occur in the video or audio being offered to the 
user. 
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